home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.july.archive / 000106_crash!kirk.safb.af.mil!BWILLS_Thu, 29 Jul 93 18:33:52 PST.msg < prev    next >
Text File  |  1993-08-31  |  1KB  |  27 lines
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Thu, 29 Jul 93 18:33:52 PST
  3. Received: from kirk.safb.af.mil by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0oLeBR-0000QMC; Thu, 29 Jul 93 13:02 PDT
  5. Message-Id: <m0oLeBR-0000QMC@crash.cts.com>
  6. Date: 29 Jul 93 15:00:00 CST
  7. From: "Barry D. Wills" <BWILLS@kirk.safb.af.mil>
  8. To: "amigae" <amigae@bkhouse.cts.com>
  9. Subject: re: Wishlist
  10.  
  11. >>* Don't know if there's a reason for this, but some E
  12. >>  module object names appear to be different, e.g. mp
  13. >>  instead of msgport, sigbit instead of mp_sigbit
  14. >
  15. >I agree, E will have a better reputation in the Amiga community
  16. >if it is 100% standardized with C='s includes...
  17.  
  18. Once you become accustomed to the modules' naming conventions it's not difficult
  19. to use the RKRMs to locate components in the modules.  What about all the code
  20. already written against E's current modules?  I myself would not look forward to
  21. converting a project the size of my EPP program (or larger!) if Wouter changes
  22. the existing component names.  Anyway, I think mp_sigbit is redundant since the
  23. component belongs to an mp object.  I'm convinced Commodore set that convention
  24. because of C programmers' infamous tendency to use such descriptive variable
  25. names as "a" and "x".  :-)
  26.  
  27. -- Barry